Translation between a first version of internet protocol and a second version of internet protocol when an application layer gateway (alg) is involved

ABSTRACT

A device may receive, from a first device, a port control protocol (PCP) request that includes a customer side translator (CLAT) prefix and one or more private internet protocol version X (IPvX) addresses. The PCP request may be received via an internet protocol version Y (IPvY) network. The device may store the CLAT prefix and the one or more private IPvX addresses using a data structure. The device may receive a packet that includes a private IPvX of the one or more private IPvX addresses and a private IPvY address that includes the CLAT prefix and a second instance of the private IPvX address. The device may use an application layer gateway (ALG). The device may translate the private IPvX address to a public IPvX address using the CLAT prefix. The device may provide the packet that includes the public IPvX address to a second device that supports IPvX.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.16/811,263, filed Mar. 6, 2020, which is a continuation of U.S. patentapplication Ser. No. 15/637,467 (now U.S. Pat. No. 10,659,356), both ofwhich are incorporated herein by reference in their entirety.

BACKGROUND

Internet protocol (IP) is a communications protocol used for sending andreceiving packets over a network (e.g., the Internet). Network addresstranslators (NATs) may provide translation of IP addresses in packetsbetween private IP addresses and public IP addresses. Furthermore, NATsmay support translation of IP addresses between different versions of IPand between the same versions of IP.

SUMMARY

According to some possible implementations, a device may receive, from afirst device that supports internet protocol version 4 (IPv4), a portcontrol protocol (PCP) request that includes a customer side translator(CLAT) prefix and one or more private IPv4 addresses. The PCP requestmay be received via an internet protocol version 6 (IPv6) network. Thedevice may establish an association between the CLAT prefix and the oneor more private IPv4 addresses. The device may receive, from the firstdevice and via the IPv6 network, a packet that includes a private IPv4address of the one or more private IPv4 addresses and an IPv6 addressthat includes the CLAT prefix and a second instance of the private IPv4address. The private IPv4 address may be associated with a payload ofthe packet. The IPv6 address may be associated with a header of thepacket. The device may translate the private IPv4 address to a publicIPv4 address using the CLAT prefix. The device may provide the packetthat includes the public IPv4 address to a second device that supportsIPv4.

According to some possible implementations, a method may includereceiving, by a device and from a first device, a port control protocol(PCP) request that includes a customer side translator (CLAT) prefix andone or more private internet protocol version X (IPvX) addresses. ThePCP request may be received via an internet protocol version Y (IPvY)network, where X is not equal to Y. The method may include storing, bythe device, the CLAT prefix and the one or more private IPvX addressesusing a data structure. The method may include receiving, by the deviceand from the first device, a packet that includes a private IPvX addressof the one or more private IPvX addresses and a private IPvY addressthat includes the CLAT prefix and a second instance of the private IPvXaddress. The device may use an application layer gateway (ALG). Themethod may include translating, by the device, the private IPvX addressto a public IPvX address using the CLAT prefix. The method may includeproviding, by the device, the packet that includes the public IPvXaddress to a second device that supports IPvX.

According to some possible implementations, a non-transitorycomputer-readable medium may store one or more instructions that, whenexecuted by one or more processors, cause the one or more processors toreceive, from a first device, a port control protocol (PCP) request thatincludes a customer side translator (CLAT) prefix and one or moreprivate internet protocol version X (IPvX) addresses. The PCP requestmay be received via an internet protocol version Y (IPvY) network. Theone or more instructions may cause the one or more processors toreceive, from the first device, a packet that includes a private IPvXaddress of the one or more private IPvX addresses and a private IPvYaddress that includes the CLAT prefix and a second instance of theprivate IPvX address. The private IPvX address may be associated with apayload of the packet, and the private IPvY address may be associatedwith a header of the packet. The one or more instructions may cause theone or more processors to translate the private IPvX address to a publicIPvX address using the CLAT prefix. The one or more instructions maycause the one or more processors to provide the packet that includes thepublic IPvX address to a second device that supports IPvX.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C are diagrams of an overview of an example implementationdescribed herein;

FIG. 2 is a diagram of an example environment in which systems and/ormethods, described herein, may be implemented;

FIG. 3 is a diagram of example components of one or more devices of FIG.2 ; and

FIG. 4 is a flow chart of an example process for sending and receivingpackets between a first device that supports internet protocol version 4(IPv4) and a second device that supports IPv4 via an internet protocolversion 6 (IPv6) network.

DETAILED DESCRIPTION

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

Some devices and/or applications may support IPv4. Other devices and/orapplications may support IPv6. NATs may be used to map an address space(e.g., IPv4, IPv6, etc.) to another address space (e.g., IPv6, IPv4,etc.) by modifying network address information in IP datagram headerswhile the network address information is being routed between networkdevices.

A 464XLAT architecture provides limited IPv4 connectivity over an IPv6network by using stateful protocol translations at core devices andstateless protocol translations at edge devices. For example, anapplication hosted by a first device may support IPv4 and may need tosend an IPv4 packet over an IPv6 network to a second device that alsosupports IPv4. In this case, the first device may use a customer sidetranslator (CLAT) to perform a stateless translation of IPv4 addressesto IPv6 addresses.

In a stateless translation, the CLAT may translate the IPv4 packet to anIPv6 packet. For example, the CLAT may translate a private IPv4 addressincluded in a header of the packet to an IPv6 address by appending aCLAT prefix to the IPv4 address. Additionally, the first device mayprovide the IPv6 packet to a network device associated with the IPv6network. In this case, the network device may use a provider sidetranslator (PLAT) to translate the IPv6 packet to an IPv4 packet, andmay translate the IPv6 address to a public IPv4 address without usingthe CLAT prefix. Furthermore, the network device may provide the IPv4packet to the second device.

However, if an application layer gateway (ALG) is used, a payload of theIPv4 packet may include private IPv4 addresses that need translation butthat are unable to be read using the CLAT of 464XLAT. In this case, theCLAT may perform a stateless translation of IPv4 addresses included in aheader of the IPv4 packet, but may be unable to translate private IPv4addresses included in the payload of the IPv4 packet. As such, when thePLAT receives the IPv6 packet, the PLAT may be unable to identify theprivate IPv4 address included in an IPv6 address that is stored in theheader of the packet when it does not have the corresponding CLATprefix. Without a way to identify the private IPv4 address, the PLAT maybe unable to translate to a public IPv4 address. Additionally, manualconfiguration of a CLAT prefix may be difficult when there are millions,even billions, of CLAT prefixes associated with internet serviceprovider (ISP) networks.

Some implementations described herein provide a network device hosting aPLAT to translate a private IPv4 address to a public IPv4 address andvice versa when the private IPv4 address is included in a payload of apacket. For example, assume a first device that supports IPv4 provides aport control protocol (PCP) request to a network device of an IPv6network. In this case, the PCP request may include a CLAT prefix and oneor more private IPv4 addresses.

Additionally, the network device may receive a first packet thatincludes a private IPv4 address of the one or more private IPv4addresses in a payload of the first packet. In this case, the networkdevice may translate the private IPv4 address to a public IPv4 addressusing the CLAT prefix obtained during the PCP request. Furthermore, thenetwork device may provide the first packet that includes the publicIPv4 address to the second device. A similar process may be used to senda second packet from the second device to the first device, using thenetwork device as an intermediary, with each device performing a reversetranslation, as described further herein.

In this way, a first device that supports IPv4 may send and receivepackets to a second device that supports IPv4 and uses an ALG, using anIPv6 network as an intermediary. Additionally, by using a PCP request toobtain a CLAT prefix, the network device conserves processing resourcesrelative to network devices with manually configured CLAT prefixes.Furthermore, automatically assigning CLAT prefixes during the PCPrequest improves scalability, and conserves network resources that mightotherwise be used to manually configure hundreds of thousands, millions,or even billions of CLAT prefixes associated with ISPs.

In the description to follow, implementations will be described in thecontext of translating from IPv4 to IPv6 or vice versa. In practice, oneor more of these implementations may equally apply to translating from afirst version of IP (referred to generally as IPvX) to a second versionof IP (referred to generally as IPvY) (where X≠Y), where the firstversion of IP is different (i.e., a later version or an earlier versionof IP) than the second version of IP.

FIGS. 1A-1C are diagrams of an overview of an example implementation 100described herein. Example implementation 100 may include a user device,a network device, and an IPv4 application server. The network device maybe included in an IPv6 network (e.g., a network capable of supportingIPv4 and/or IPv6) and may host a PLAT. The user device may host an IPv4application and a CLAT (e.g., a CLAT may run as a daemon).

As shown in FIG. 1A, and by reference number 105, the user device mayconfigure a PCP request to include a CLAT prefix and one or more privateIPv4 addresses. For example, the user device may configure a PCP requestto include a CLAT prefix (e.g., 2001:db8:bbbb::/96) and a private IPv4addresses (e.g., 198.51.100.1) in a header of the PCP request. As shown,the CLAT prefix and the private IPv4 address may be stored using a PCPoptions portion of the header.

As shown by reference number 110, the network device may receive the PCPrequest from the user device. In this case, and as shown by referencenumber 115, the network device may establish an association between theCLAT prefix and the private IP address. For example, the network devicemay store the CLAT prefix and the private IP address using a datastructure, such as a NAT mapping table. As shown by reference number120, the network device may provide a PCP response to the user device.The PCP response may indicate to the user device that the PCP requesthas been received by the network device.

In this way, the network device uses a data structure to associate theCLAT prefix with the private IPv4 address, and may use the datastructure when performing NATs, as described further herein.

As shown in FIG. 1B, and by reference number 125, the CLAT of the userdevice may receive a packet (e.g., an IPv4 packet) from the IPv4application hosted by the user device. The packet may include theprivate IPv4 address within a payload of the packet. Additionally, theheader of the packet may include a second instance of the private IPv4address. As shown by reference number 130, the CLAT may translate thepacket from an IPv4 packet to an IPv6 packet using a statelesstranslation. In this case, the CLAT may append the CLAT prefix to thesecond instance of the private IPv4 address to convert the secondinstance of the private IPv4 address to an IPv6 address. However, thestateless translation will not translate the private IPv4 addressincluded in the payload of the packet.

As shown by reference number 135, the CLAT may provide the IPv6 packetto the network device. For example, the network device may provide theIPv6 packet that includes the private IPv4 address in the payload (e.g.,198.51.100.1) and the second instance of the private IPv4 address whichis embedded in the IPv6 address (e.g., 2001:db8:bbbb::198.51.100.1)included in the header.

As shown by reference number 140, the network device may translate theprivate IPv4 address included in the payload to a public IPv4 address.For example, the network device may identify the second instance of theprivate IPv4 address included in the IPv6 address by removing the CLATprefix from the IPv6 address. Furthermore, the network device may assigna public IPv4 address to the identified second instance of the privateIPv4 address, and may update the NAT mapping table to store theassociation between the identified second instance of the private IPv4address and the assigned public IPv4 address.

Additionally, the network device may search the payload of the IPv6packet to identify any private IPv4 addresses (e.g., 198.51.100.1), andmay search the NAT mapping table for matching private IPv4 addresses. Inthis case, the network device may replace the identified private IPv4addresses included in the payload (e.g., 198.51.100.1) with public IPv4addresses that are associated with the matching private IPv4 addresses(e.g., 113.1.1.2).

Additionally, the network device may translate the packet from an IPv6packet to an IPv4 packet. For example, the network device may translatethe packet to an IPv4 packet to allow the packet to be processed by theIPv4 application server. In this case, the payload of the IPv4 packetmay include the public IPv4 address.

In this way, the network device may translate the private IP addressincluded in the payload of the packet to a public IP address.

As shown in FIG. 1C, and by reference number 145, the network device mayprovide the packet (e.g., the IPv4 packet) to the IPv4 applicationserver. In this case, the payload of the packet may include the publicIPv4 address (e.g., 113.1.1.2). As shown by reference number 150, thenetwork device may receive a reply packet from the IPv4 applicationserver. For example, the IPv4 application server may initiate aconnection based on the public IPv4 address included in the payload ofthe IPv4 packet. In this case, the IPv4 application server may providethe reply packet to the network device. In some cases, a payload of thereply packet may include the public IPv4 address.

As shown by reference number 155, the network device may translate thepublic IPv4 address to the private IPv4 address. For example, thenetwork device may translate the public IPv4 address to the private IPv4address in the same manner described above (e.g., using the NAT mappingtable that associates the public IPv4 address, the CLAT, and the privateIPv4 address). Additionally, the network device may translate the replypacket from an IPv4 packet to an IPv6 packet, in the same manner asdescribed above.

As shown by reference number 160, the network device may provide thereply packet (e.g., the IPv6 packet) to the user device. In this case,the payload of the reply packet may include the private IPv4 address(e.g., 198.51.100.1). As shown by reference number 165, the user devicemay use the CLAT to translate the reply packet from an IPv6 packet to anIPv4 packet. As shown by reference number 170, the CLAT may provide thereply packet to the IPv4 application.

In this way, packet transmission in an ALG context may occur in an IPv4to IPv6 to IPv4 scenario.

As indicated above, FIGS. 1A-1C are provided merely as an example. Otherexamples are possible and may differ from what was described with regardto FIGS. 1A-1C. For example, in some implementations, a device (e.g., arouter, a gateway, an edge device, etc.) may host the CLAT and may beincluded in a local network with one or more additional devices (e.g., alaptop, a desktop, a mobile phone, etc.). In this case, the additionaldevices may provide traffic (e.g., packets) to the device, and thedevice may provide the traffic to an IPv4 server device using an IPv6network as an intermediary.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods, described herein, may be implemented. As shown in FIG. 2, environment 200 may include one or more peer devices 210, one or morenetwork devices 220-1 through 220-N(N≥1) (hereinafter referred tocollectively as “network devices 220”, and individually as “networkdevice 220”), one or more IPv4 server devices 230, and/or a network 240.Devices of environment 200 may interconnect via wired connections,wireless connections, or a combination of wired and wirelessconnections.

Peer device 210 includes one or more devices capable of receiving and/orproviding network traffic. For example, peer device 210 may include atraffic transfer device, such as a router, a gateway, a switch, afirewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxyserver, a server executing a virtual machine, etc.), a load balancer, ora similar type of device. Additionally, or alternatively, peer device210 may include an endpoint device that is a source or a destination fornetwork traffic. For example, peer device 210 may include a computer ora similar type of device.

In some implementations, peer device 210 may receive network trafficfrom and/or may provide network traffic to other peer devices 210. Forexample, a first peer device 210 may provide network traffic (e.g., anIPv4 packet) to a second peer device 210 that hosts a CLAT. In thiscase, the second peer device 210 may provide the network traffic tonetwork device 220 via an IPv6 network. Additionally, the second peerdevice 210 may receive network traffic (e.g., a reply IPv4 packet) fromnetwork device 220, and may provide the network traffic to the firstpeer device 210. In some implementations, peer device 210 may host anapplication that supports IPv4, and may provide network traffic (e.g.,an IPv4 packet associated with the application) to and/or receivenetwork traffic from network device 220.

Network device 220 includes one or more devices (e.g., one or moretraffic transfer devices) capable of processing, forwarding, and/ortransferring traffic between peer devices (e.g., peer devices 210)and/or traffic transfer devices (e.g., other network devices 220). Forexample, network device 220 may include a router, such as a labelswitching router (LSR), a label edge router (LER), an ingress router, anegress router, a provider router (e.g., a provider edge router, aprovider core router, etc.), a virtual router, or the like.Additionally, or alternatively, network device 220 may include agateway, a switch, a firewall, a hub, a bridge, a reverse proxy, aserver (e.g., a proxy server, a cloud server, a data center server,etc.), a load balancer, or another type of traffic transfer device. Insome implementations, network device 220 may be a physical deviceimplemented within a housing, such as a chassis. In implementations,network device 220 may be a virtual device implemented by one or morecomputer devices of a cloud computing environment or a data center.

IPv4 server device 230 includes one or more devices capable of receivingand/or providing network traffic. For example, IPv4 server device 230may include a server device (e.g., a host server, a web server, anapplication server, a data center server, a server of a cloud computingenvironment, etc.) or a similar device. In some implementations, IPv4server device 230 may receive network traffic from and/or providenetwork traffic to network device 220 via an IPv6 network.

Network 240 includes one or more wired and/or wireless networks. Forexample, network 240 may include a cellular network (e.g., a fifthgeneration (5G) network, a fourth generation (4G) network, such as along-term evolution (LTE) network, a third generation (3G) network, acode division multiple access (CDMA) network, etc.), a public landmobile network (PLMN), a local area network (LAN), a wide area network(WAN), a metropolitan area network (MAN), a telephone network (e.g., thePublic Switched Telephone Network (PSTN)), a private network, an ad hocnetwork, an intranet, the Internet, a fiber optic-based network, a cloudcomputing network, or the like, and/or a combination of these or othertypes of networks.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as an example. In practice, there may be additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseshown in FIG. 2 . Furthermore, two or more devices shown in FIG. 2 maybe implemented within a single device, or a single device shown in FIG.2 may be implemented as multiple, distributed devices. Additionally, oralternatively, a set of devices (e.g., one or more devices) ofenvironment 200 may perform one or more functions described as beingperformed by another set of devices of environment 200.

FIG. 3 is a diagram of example components of a device 300. Device 300may correspond to peer device 210, network device 220, and/or IPv4server device 230. In some implementations, peer device 210, networkdevice 220, and/or IPv4 server device 230 may include one or moredevices 300 and/or one or more components of device 300. As shown inFIG. 3 , device 300 may include one or more input components 305-1through 305-B (B≥1) (hereinafter referred to collectively as inputcomponents 305, and individually as input component 305), a switchingcomponent 310, one or more output components 315-1 through 315-C(C≥1)(hereinafter referred to collectively as output components 315, andindividually as output component 315), and a controller 320.

Input component 305 may be points of attachment for physical links andmay be points of entry for incoming traffic, such as packets. Inputcomponent 305 may process incoming traffic, such as by performing datalink layer encapsulation or decapsulation. In some implementations,input component 305 may send and/or receive packets. In someimplementations, input component 305 may include an input line card thatincludes one or more packet processing components (e.g., in the form ofintegrated circuits), such as one or more interface cards (IFCs), packetforwarding components, line card controller components, input ports,processors, memories, and/or input queues. In some implementations,device 300 may include one or more input components 305.

Switching component 310 may interconnect input components 305 withoutput components 315. In some implementations, switching component 310may be implemented via one or more crossbars, via busses, and/or withshared memories. The shared memories may act as temporary buffers tostore packets from input components 305 before the packets areeventually scheduled for delivery to output components 315. In someimplementations, switching component 310 may enable input components305, output components 315, and/or controller 320 to communicate.

Output component 315 may store packets and may schedule packets fortransmission on output physical links. Output component 315 may supportdata link layer encapsulation or decapsulation, and/or a variety ofhigher-level protocols. In some implementations, output component 315may send packets and/or receive packets. In some implementations, outputcomponent 315 may include an output line card that includes one or morepacket processing components (e.g., in the form of integrated circuits),such as one or more IFCs, packet forwarding components, line cardcontroller components, output ports, processors, memories, and/or outputqueues. In some implementations, device 300 may include one or moreoutput components 315. In some implementations, input component 305 andoutput component 315 may be implemented by the same set of components(e.g., and input/output component may be a combination of inputcomponent 305 and output component 315).

Controller 320 includes a processor in the form of a central processingunit (CPU), a graphics processing unit (GPU), an accelerated processingunit (APU), a microprocessor, a microcontroller, a digital signalprocessor (DSP), a field-programmable gate array (FPGA), anapplication-specific integrated circuit (ASIC), and/or another type ofprocessor. The processor is implemented in hardware, firmware, or acombination of software and hardware. In some implementations,controller 320 may include one or more processors that can be programmedto perform a function.

In some implementations, controller 320 may include a random accessmemory (RAM), a read only memory (ROM), and/or another type of dynamicor static storage device (e.g., a flash memory, a magnetic memory, anoptical memory, etc.) that stores information and/or instructions foruse by controller 320.

In some implementations, controller 320 may communicate with otherdevices, networks, and/or systems connected to device 300 to exchangeinformation regarding network topology. Controller 320 may create NATmapping tables based on the network topology information, createforwarding tables based on the NAT mapping tables, and forward theforwarding tables to input components 305 and/or output components 315.Input components 305 and/or output components 315 may use the forwardingtables to perform route lookups for incoming and/or outgoing packets.

Controller 320 may perform one or more processes described herein.Controller 320 may perform these processes in response to executingsoftware instructions stored by a non-transitory computer-readablemedium. A computer-readable medium is defined herein as a non-transitorymemory device. A memory device includes memory space within a singlephysical storage device or memory space spread across multiple physicalstorage devices.

Software instructions may be read into a memory and/or storage componentassociated with controller 320 from another computer-readable medium orfrom another device via a communication interface. When executed,software instructions stored in a memory and/or storage componentassociated with controller 320 may cause controller 320 to perform oneor more processes described herein. Additionally, or alternatively,hardwired circuitry may be used in place of or in combination withsoftware instructions to perform one or more processes described herein.Thus, implementations described herein are not limited to any specificcombination of hardware circuitry and software.

The number and arrangement of components shown in FIG. 3 are provided asan example. In practice, device 300 may include additional components,fewer components, different components, or differently arrangedcomponents than those shown in FIG. 3 . Additionally, or alternatively,a set of components (e.g., one or more components) of device 300 mayperform one or more functions described as being performed by anotherset of components of device 300.

FIG. 4 is a flow chart of an example process 400 for sending andreceiving packets between a first device that supports internet protocolversion 4 (IPv4) and a second device that supports IPv4 via an internetprotocol version 6 (IPv6) network. In some implementations, one or moreprocess blocks of FIG. 4 may be performed by network device 220. In someimplementations, one or more process blocks of FIG. 4 may be performedby another device or a group of devices separate from or includingnetwork device 220, such as peer device 210 and/or IPv4 server device230.

As shown in FIG. 4 , process 400 may include receiving, from a device, aport control protocol (PCP) request that includes a customer sidetranslator (CLAT) prefix and one or more private internet protocolversion 4 (IPv4) addresses (block 410). For example, network device 220may receive, from peer device 210, a PCP request that includes a CLATprefix and one or more private IPv4 addresses in a header of the PCPrequest. The CLAT prefix may serve as a key that a CLAT and/or aprovider side translator (PLAT) may use when performing a translationbetween different versions of IP (e.g., IPv4 to IPv6, IPv6 to IPv4,etc.). Additionally, after receiving the PCP request, network device 220may store the CLAT prefix and the one or more private IPv4 addressesusing a data structure (e.g., a NAT mapping table, a forwarding table,or the like).

In some implementations, peer device 210 may configure a PCP request toinclude a CLAT prefix and one or more private IPv4 addresses. Forexample, peer device 210 may configure a header of the PCP request toinclude a CLAT prefix and one or more private IPv4 addresses in anoption portion of the header. The option portion may include a set ofbits reserved for performing additional functionality (e.g.,functionality not ordinarily included in a PCP request). In this case, aPCP opcode within the PCP header may be extended using the optionportion (e.g., a MAP opcode, a PEER opcode, an ANNOUNCE opcode, etc.).

As an example, assume that an application using IPv4 is hosted on peerdevice 210 and that peer device 210 hosts the CLAT. In this case, peerdevice 210 may configure a PCP request by including a CLAT prefix and aprivate IPv4 address in an option portion of the PCP header.

As another example, assume that one or more first peer devices 210(e.g., a work station, a laptop, a mobile device, etc.) are using asecond peer device 210 (e.g., a router, a gateway, a modem, etc.) toaccess the Internet. Further assume the one or more first peer devices210 are associated with one or more private IPv4 addresses and that thesecond peer device 210 hosts the CLAT. In this case, the second peerdevice 210 may configure a PCP request by including a CLAT prefix andthe one or more private IPv4 addresses in an option portion of the PCPheader.

In some implementations, network device 220 may process the PCP requestto identify the CLAT prefix and the one or more private IPv4 addresses.For example, network device 220 may process a header of the PCP requestto identify the CLAT prefix and the one or more private IPv4 addressesincluded in the option portion of the PCP header.

In some implementations, network device 220 may store the CLAT prefixand the one or more private IPv4 addresses. For example, network device220 may store the CLAT prefix and the one or more private IPv4 addressesusing a data structure, such as a linked-list, an array, a tree, a hashtable, and/or the like. In some cases, network device 220 may store theCLAT prefix and the one or more private IPv4 addresses separately. Inother cases, network device 220 may concatenate the CLAT prefix to eachthe one or more private IPv4 addresses, and may store the concatenatedvalue. In this way, network device 220 is able to establish anassociation between the CLAT prefix and the one or more private IPv4addresses.

In some implementations, network device 220 may provide a PCP responseto peer device 210. For example, network device 220 may provide a PCPresponse indicating that the PCP request was received. In this case, thedevice hosting the CLAT receives acknowledgement indicating that aconnection is established between peer device 210 and network device220, and that peer device 210 may begin sending packets to networkdevice 220.

In this way, network device 220 may use the CLAT prefix and the one ormore private IPv4 addresses to translate private IPv4 addresses that maybe included in a payload of subsequent packets transmitted over the IPv6network, as described further herein.

As further shown in FIG. 4 , process 400 may include receiving, from thedevice, a first packet that includes a private IPv4 address, of the oneor more private IPv4 addresses, the private IPv4 address being includedin a payload of the first packet (block 420). For example, networkdevice 220 may receive, from peer device 210, a first packet thatincludes a private IPv4 address in a payload of the packet and a secondinstance of the private IPv4 address in a header of the packet. In somecases, the payload of the packet may include a set of private IPv4addresses, and only one private IPv4 address of the set of private IPv4addresses may have a second instance included in the header of thepacket.

In some implementations, prior to network device 220 receiving the firstpacket, peer device 210 may translate the first packet from an IPv4packet to an IPv6 packet. For example, a CLAT of peer device 210 mayperform a stateless translation of the packet to translate the firstpacket from an IPv4 packet to an IPv6 packet. In this case, the CLAT maytranslate the second instance of the private IPv4 address to an IPv6address by appending the CLAT prefix to the second instance of theprivate IPv4 address. Additionally, the CLAT may be unable to translatethe private IPv4 addresses included in the payload of the first packet.

In some implementations, network device 220 may receive an IPv6 packetfrom peer device 210. For example, network device 220 may receive, viaan IPv6 network, an IPv6 packet that includes the private IPv4 addressin a payload of the IPv6 packet. As an example, assume peer device 210hosts an IPv4 application and a CLAT. Further assume that peer device210 provides a packet to network device 220. In this case, networkdevice 220 may support ALG (e.g., to manage file transfer protocol(FTP), session initiation protocol (SIP), etc.), and may receive thepacket (e.g., as an IPv6 packet) that includes a private IPv4 address ina payload of the packet.

In this way, network device 220 is able to receive a first packet thatincludes a private IPv4 address in a payload of the first packet, andmay perform one or more actions to translate the private IPv4 address toa public IPv4 address.

As further shown in FIG. 4 , process 400 may include translating theprivate IPv4 address to a public IPv4 address (block 430). For example,network device 220 may identify the second instance of the private IPv4address from the IPv6 address, and may utilize NAT to translate theprivate IPv4 address included in the payload to a public IPv4 address,as described in detail below.

In some implementations, network device 220 may identify the secondinstance of the private IPv4 address that is included in the IPv6address. For example, network device 220 may identify the secondinstance of the private IPv4 address by removing the CLAT prefix fromthe IPv6 address. In this case, network device 220 may assign a publicIPv4 address to the second instance of the private IPv4 address using anIP address selection algorithm, such as an algorithm that selects ahighest available public IPv4 address, a lowest available public IPv4address, a random public IPv4 address (e.g., using a random numbergenerator), or the like. Additionally, network device 220 may update theNAT mapping table to store the IPv6 address and an association betweenthe second instance of the private IPv4 address and the assigned publicIPv4 address.

Additionally, network device 220 may search the payload of the IPv6packet to identify the private IPv4 address, and may search the NATmapping table for matching private IPv4 addresses (e.g., the secondinstance of the private IPv4 address). If a match is located, networkdevice 220 may use the NAT mapping table to identify the assigned publicIPv4 address that is associated with the second instance of the privateIPv4 address, and may replace the private IPv4 address in the payload ofthe packet with the assigned public IPv4 address.

Additionally, network device 220 may translate the first packet from anIPv6 packet to an IPv4 packet. For example, network device 220 maytranslate the first packet to an IPv4 packet to allow the first packetto be processed by IPv4 server device 230. In this case, the firstpacket may be translated to an IPv4 packet, and may include the selectedpublic IPv4 address in a payload of the first packet.

In this way, network device 220 may translate the private IPv4 addressincluded in the payload to a public IPv4 address.

As further shown in FIG. 4 , process 400 may include providing the firstpacket that includes the public IPv4 address to a server device toreceive a second packet from the server device (block 440). For example,network device 220 may provide the first packet that includes the publicIPv4 address to IPv4 server device 230, which may cause IPv4 serverdevice 230 to provide a second packet (e.g., a reply packet). In thiscase, IPv4 server device 230 may initiate a connection based on thepublic IPv4 address included in the payload of the packet. In somecases, the public IPv4 address may be included in a payload of thesecond packet.

In this way, a first packet that includes a private IPv4 address in apayload of the packet may be transmitted from a first device thatsupports IPv4 to a second device that supports IPv4, via an IPv6network, even if one or more devices handling transmission of the firstpacket use an ALG. Furthermore, a second packet (e.g., a reply packet)may be provided from the second device to the first device, using theIPv6 network, as described further herein.

As further shown in FIG. 4 , process 400 may include translating thepublic IPv4 address included in the second packet to the private IPv4address (block 450). For example, network device 220 may use NAT totranslate the public IPv4 address in the payload of the second packet(e.g., the IPv4 packet) to the private IPv4 address.

In some implementations, network device 220 may translate the publicIPv4 address to the private IPv4 address. For example, network device220 may search the payload of the second packet to identify the publicIPv4 address, and may use the public IPv4 address to search the NATmapping table for a matching public IPv4 address. In this case, networkdevice 220 may identify the private IPv4 address that is associated withthe public IPv4 address, and may replace the public IPv4 address withthe identified private IPv4 address.

Additionally, network device 220 may translate the second packet from anIPv4 packet to an IPv6 packet. For example, network device 220 maytranslate the second packet to an IPv6 packet to allow the second packetto be provided to peer device 210 via the IPv6 network. In this case,the second packet may be translated to an IPv6 packet, and may includethe private IPv4 address in the payload of the second packet.

In this way, network device 220 may translate the public IPv4 address tothe private IPv4 address.

As further shown in FIG. 4 , process 400 may include providing thesecond packet to the device (block 460). For example, network device 220may provide the second packet to peer device 210, and peer device 210(e.g., the CLAT of peer device 210) may translate the second packet andprovide the second packet to one or more applications and/or devicesthat support IPv4.

In some implementations, peer device 210 may translate the second packetfrom an IPv6 packet to an IPv4 packet. For example, peer device 210 maytranslate the second packet to an IPv4 packet in a manner describedelsewhere herein. In this way, peer device 210 is able to translate thesecond packet to an IPv4 packet to allow the second packet to betransmitted to applications and/or devices that support IPv4.

In some implementations, the CLAT of peer device 210 may provide thesecond packet to an application hosted by peer device 210 that supportsIPv4. In some implementations, the CLAT of peer device 210 may providethe second packet to one or more additional peer devices 210 thatsupport IPv4.

In this way, devices and/or applications that support IPv4 are able toreceive reply packets from IPv4 server device 230, using an IPv6 networkas an intermediary, even when the private IPv4 addresses associated withthe devices and/or applications are included in a payload of an initialpacket.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4 . Additionally, or alternatively, two or more of theblocks of process 400 may be performed in parallel.

In this way, a peer device 210 that supports IPv4 may send and receivepackets to IPv4 server device 230, using an IPv6 network as anintermediary. Additionally, by using a PCP request to obtain a CLATprefix, network device 220 conserves processing resources relative tonetwork devices with manually configured CLAT prefixes. Furthermore,automatically assigning CLAT prefixes during the PCP request improvesscalability, and conserves network resources that might otherwise beused to manually configure hundreds of thousands, millions, or evenbillions of CLAT prefixes associated with ISPs.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or may be acquired from practice of theimplementations.

As used herein, the term component is intended to be broadly construedas hardware, firmware, and/or a combination of hardware and software.

It will be apparent that systems and/or methods, described herein, maybe implemented in different forms of hardware, firmware, or acombination of hardware and software. The actual specialized controlhardware or software code used to implement these systems and/or methodsis not limiting of the implementations. Thus, the operation and behaviorof the systems and/or methods were described herein without reference tospecific software code—it being understood that software and hardwarecan be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of possible implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of possible implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items(e.g., related items, unrelated items, a combination of related andunrelated items, etc.), and may be used interchangeably with “one ormore.” Where only one item is intended, the term “one” or similarlanguage is used. Also, as used herein, the terms “has,” “have,”“having,” or the like are intended to be open-ended terms. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A device, comprising: a memory; and one or more processors to: translate a first internet protocol version 4 (IPv4) packet to an internet protocol version 6 (IPv6) packet that includes: a private IPv4 address of one or more private IPv4 addresses, and a private IPv6 address that includes a copy of the private IPv4 address; provide the IPv6 packet, wherein the private IPv4 address is translated to a public IPv4 address using a customer side translator (CLAT) prefix, and wherein the private IPv4 address is replaced with the public IPv4 address; receive, based on providing the IPv6 packet, a reply packet that includes the private IPv4 address; and translate the reply packet to a second IPv4 packet.
 2. The device of claim 1, wherein translating the IPv4 packet to the IPv6 packet is based on receiving a response to a port control protocol request.
 3. The device of claim 1, wherein the IPv6 packet is provided to another device, and wherein the reply packet is received from the another device.
 4. The device of claim 1, wherein a translator component associated with the device provides the second IPv4 packet to an application hosted by the device.
 5. The device of claim 4, wherein the translator component is associated with a CLAT associated with the device, and wherein the application is associated with IPv4.
 6. The device of claim 1, wherein the reply packet is associated with IPv6.
 7. A first device, comprising: a memory; and one or more processors to: establish an association between a customer side translator (CLAT) prefix and one or more private internet protocol version 4 (IPv4) addresses; receive, from a second device, a packet that includes: a private IPv4 address, of the one or more private IPv4 addresses, and an internet protocol version 6 (IPv6) address that includes the CLAT prefix and a copy of the private IPv4 address; translate the private IPv4 address to a public IPv4 address using the CLAT prefix; identify, based on the packet, the private IPv4 address; replace the private IPv4 address, associated with the packet, with the public IPv4 address; and provide, based on replacing the private IPv4 address, the packet to a third device that supports IPv4.
 8. The device of claim 7, wherein the CLAT prefix and the one or more private IPv4 addresses are associated with a port control protocol (PCP) request.
 9. The device of claim 8, wherein the PCP request is received from the second device.
 10. The device of claim 8, wherein the PCP request is received via an IPv6 network.
 11. The device of claim 7, wherein information associated with the CLAT prefix is received via an IPv6 network.
 12. The device of claim 7, wherein the device uses an application layer gateway.
 13. The device of claim 7, wherein the one or more processors, when translating the private IPv4 address to the public IPv4 address, are to: remove the CLAT prefix from the IPv6 address; identify, based on removing the CLAT prefix, the copy; and update a data structure to associate the copy and the public IPv4 address.
 14. The device of claim 7, wherein the one or more processors are to: process a port control protocol (PCP) request received from the second device to identify the CLAT prefix and the one or more IPv4 addresses.
 15. A method, comprising: establishing, by a first device, an association between a customer side translator (CLAT) prefix and one or more private internet protocol version 4 (IPv4) addresses; receiving, by the first device and from a second device, a packet that includes: a private IPv4 address, of the one or more private IPv4 addresses, and an internet protocol version 6 (IPv6) address that includes the CLAT prefix and a copy of the private IPv4 address; translating, by the first device, the private IPv4 address to a public IPv4 address using the CLAT prefix; identifying, by the first device and based on the packet, the private IPv4 address; replacing, by the first device, the private IPv4 address with the public IPv4 address, wherein the private IPv4 address is associated with the packet; and providing, by the first device and based on replacing the private IPv4 address, the packet to a third device that supports IPv4.
 16. The device of claim 15, wherein the CLAT prefix and the one or more private IPv4 addresses are associated with a port control protocol (PCP) request.
 17. The device of claim 16, wherein the PCP request is received from the second device.
 18. The device of claim 16, wherein the PCP request is received via an IPv6 network.
 19. The device of claim 15, wherein information associated with the CLAT prefix is received via an IPv6 network.
 20. The device of claim 15, wherein the one or more processors, when translating the private IPv4 address to the public IPv4 address, are to: remove the CLAT prefix from the IPv6 address; identify, based on removing the CLAT prefix, the copy; and update a data structure to associate the copy and the public IPv4 address. 